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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 description of the Out-of-Band Transcoder Control for speech services. It 
describes the principles and procedures to support Transcoder Free Operation, Tandem Free Operation and the 
interworking between TrFO and TFO. Transcoder at the edge is also part of the present document. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following definition apply: 

Codec: device to encode information from its original representation into an encoded form and to decode encoded 
information into its original representation 

Tandem Free Operation: configuration of a connection with two transcoders that support TFO protocol and whose 
external coding schemes are compatible, thus enabling compressed speech to pass between them 

NOTE 1 : When the TFO protocol is not supported by both transcoders or the coding schemes are not compatible 
then normal "Tandem" operation occurs and PCM encoded speech is passed between them. 

Transcoder: device to change the encoding of information from one particular encoding scheme to a different one, 
most commonly to/from a compressed speech algorithm from/to PCM. 

Transcoder Free Operation: configuration of a speech or multimedia call for which no transcoder device is physically 
present in the communication path and hence no control or conversion or other functions can be associated with it 

Out of Band Transcoder Control: capability of a system to negotiate the types of codecs and codec modes on a call 
per call basis through out-of-band signalling, required to establish Transcoder Free Operation. 

Default PCM Codec: network default 64kb/s codec for speech in PCM domain 

NOTE 2: For example ITU G.71 1 A-law. 

Transcoding free link (TrFL): bearer link, where compressed voice is being carried between bearer endpoints 

NOTE 3: Within the UMTS network, the compressed voice is transmitted in lu/ Nb User Plane format, depending 
on the related interface. 

Tandem free link (TFOL): bearer link between transcoders that are operating in Tandem Free Operation mode, i.e. 
bypassing the transcoding functions 

NOTE 4: The involved transcoders can be a UMTS transcoder or a GSM TRAU with TFO functionality. 

Transcoder free operation (TrFO): calls that have no transcoders involved in the connection between the source 
codecs 

NOTE 5: For mobile to mobile calls this is UE to UE, although the connection could be UE to another type of 
terminal. TrFO operation is considered a concatenation of TrFLs between RNCs. 

NOTE 6: In case of mobile to fixed network calls the term "Transcoder free operation" is applicable for the TrFLs 
carrying compressed speech. The TrFO usually ends at the Gateway to the PSTN where the speech is 
transcoded e.g. to G.711. 

Tandem free and Transcoding free operation (TaTrFO): concatenation of "transcoding free links" and "tandem free 
links" 

lu Framing: framing protocol used for the speech packets on both the lu User Plane interface and the Nb User Plane 
interface 

NOTE 7: The lu framing protocol is specified by [4]. 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations defined in 3GPP TS 21.905 and the following apply: 

APM Application Transport Mechanism 

BC Bearer Control 

BlCC Bearer Independent Call Control 

CC Call Control 

CCD Conference Call Device 

CFNRc Call Forward Not Reachable 

CFNRy Call Forward on No Reply 

IN Intelligent Network 

luFP lu Framing Protocol 

OoBTC Out-of-Band Transcoder Control 

QoS Quality of Service 

RAB Radio Access Bearer 

TFO Tandem Free Operation 

TICC Transport Independent Call Control 

TrFO Transcoder Free Operation 

UP User Plane 



4 Out-of-Band Transcoder control functionality 

Cellular networks depend heavily on codecs to provide their services. Codecs are necessary to compress speech in order 
to utilise efficiently the expensive bandwidth resources both in the radio interface and in the transmission networks. 

Unnecessary transcoding of speech significantly degrades quality and, therefore, cellular systems try to avoid it for 
mobile-to-mobile calls when both UEs and the network support a common codec type. 

Although the main reason for avoiding transcoding in mobile-to-mobile calls has been speech quality, the transmission 
of compressed information in the CN and CN-CN interface of the cellular network also offers the possibility of 
bandwidth savings. Therefore Out-of-Band Transcoder Control is not limited to mobile-to -mobile calls but can be 
applied for calls to or from an external network as well. 

Digital cellular systems support an increasing number of codec types. As a result, in order to allocate transcoders for a 
call inside the network, and to select the appropriate codec type inside the UEs, signalling procedures are defined to 
convey the codec type selected for a call to all the affected nodes (UEs and (potential) transcoding points inside the 
network). Also, codec negotiation capabilities are being defined to enable the selection of a codec type supported in all 
the affected nodes, i.e. to resolve codec mismatch situations. This codec negotiation maximises the chances of operating 
in compressed mode end-to-end for mobile-to-mobile calls. 

To allow transport of information in a compressed way in transmission networks, these networks make use of the 
transport -independent call control protocol as specified in [8] that provides means for signalling codec information, 
negotiation and selection of codecs end-to-end. 

4.1 OoBTC Requirements 

The OoBTC mechanism shall support the following: 

The capability to negotiate the preferred codec type to be used between two end nodes and to avoid the use of 
transcoders in the network at call set-up. 

The originating UE indicates the list of its supported codec types for codec negotiation. This list shall be conveyed to 
the terminating MSC. The terminating UE indicates its list of supported codec types to the terminating MSC. The 
terminating MSC shall convey the selected codec to the originating MSC, which then indicates the selected codec to the 
originating UE. 

Where no compatible codec type can be selected between the UEs then the default PCM coding shall be selected. 
Therefore, the default PCM codec shall always be included in the codec list for OoBTC. The originating MSC shall 
insert a transcoder in the path from the originating UE. Codec selection for the terminating UE is then performed within 
the terminating MSC, independently of the originating MSC. 
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NOTE: For a codec type supporting various modes, the described functionality shall also be applicable to 

negotiate the set of codec modes common to originating and terminating UEs. Other negotiations such as 
Initialisation and Rate control are performed at a later point in time by the lu framing protocol. 

The capability to control the presence of transcoders in the network after call set-up. 

Where a change to the call state of a transcoder free connection occurs, such that compressed speech cannot be 
maintained, it shall be possible to insert a transcoder or pair of transcoders where needed in the path. If this results in 
change to the encoding of the speech in other nodes then it shall be possible to inform the end points of this segment 
that the speech coding is changed. Such examples where this could occur are: 

SS interruptions (e.g. A to B call connection becomes to multiparty call connection.) 

Handover to an incompatible partner. 

Synchronisation loss 

Where a change in call state as described above is temporary then it shall be possible to return to a transcoder free 
connection by removing the inserted transcoders and informing the endpoints that the connection has resumed to 
compressed speech encoding. 

The codec types comprise codecs for speech in the first phase of the present document. The transcoder control 
should have enough expandability to support future enhancements of codec types. 

The transcoder control procedure shall not cause a perceivable time lag in the cases of establishing transcoder 
free connection and reverting to normal (double transcoded) call connection in the cases described above for 
control of the presence of transcoders. 

The capability to insert transcoder (in cases where a TrFO connection is not possible) at the most appropriate 
location, i.e. to save bandwidth it should be located at the CN edge between an ATM or IP transport network and 
a STM network. When Transcoders are inserted, the OoBTC procedures shall provide support for TFO for 
inband codec negotiation and transmission of compressed speech. 

When a transport network cannot maintain compressed voice then reversion to the default PCM coding shall 
occur. A transcoder shall be inserted at that point and OoBTC procedures terminated. TrFO link is then 
possible between that point and the preceding nodes. 

When a Non-TrFO call reaches the UMTS CN then OoBTC procedures are initiated from that point and after 
codec negotiation has been performed, if compressed voice can be supported through the CN then a 
transcoder is inserted at the edge of the CN. 

- The OoBTC signalling procedures shall be supported by the call control protocol on the Nc interface, for 
example codec negotiation, codec modification, codec list modification, codec renegotiation, and codec list re- 
negotiation. BICC CS2 (see 3GPP TS 29.205 [6]) supports such a mechanism, through the APM procedures 
defined by [7]. 

If TMR = 3. IKhz Audio is set for incoming calls, this shall be kept if OoBTC is intiated at the edge of the 
PLMN. 

For mobile originating calls, TMR=speech shall be used for speech calls with OoBTC. For other TMR values 
OoBTC shall not be used. 

The OoBTC signalling procedures shall be supported by the bearer control protocol on the lu and Nb interfaces, 
for example to increase the bandwidth of the bearer (if needed) in the procedures for the codec modification. 

4.2 Relationship between OoBTC and In-band TFO 

OoBTC is used before call set-up to attempt to establish an UE-UE transcoder free connection. If successful the result is 
a saving of transcoding equipment in the path and provides a cost efficient transmission. 

The In-band TFO protocol (described in [10]) is activated after call set-up only if transcoders are inserted in the path. In 
case two transcoders in tandem (a pair of transcoders with PCM coding between them) are able to communicate to each 
other (both support TFO), then the inband TFO protocol allows the transcoders to compare coding schemes. If 
compatible codec types exist, the transcoders are able to overwrite the PCM coding with the pure compressed speech 
(effectively bypassing the transcoding functions). In-band TFO provides fast fallback mechanisms in case the TFO 
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connection can not be maintained (insertion of CCD, DTMF, tones, etc). In-band TFO provides no direct saving of 
transmission costs. 

If the OoBTC fails to establish the TrFO and transcoders are required, then in-band TFO may be used after call set-up. 
Inband TFO shall be the fallback mechanism when transcoders cannot be avoided, either at set-up or during the 
communication phase. In-band TFO shall be used for interworking with the 2G systems (e.g. GSM). 



4.3 Lawful interception 



The TrFO shall be maintained if the interception is made due to the lawful interception. Two decoders are needed to 
monitor the TrFO call. 

Lawful interception shall not have any influence on the establishment or maintenance of the TrFO connection in order 
to avoid any audible effect in speech quality or noticeable effect in speech delay to the end users. 

The existing requirements for lawful interception shall be considered, these are described in [9]. 



5 General Principles 

5.1 Network Model 

The codec negotiation mechanism (OoBTC) is designed to work in the general situation where more than two call 
control (CC) nodes need to participate in the codec negotiation. The codec negotiation mechanism works as follows: 

Originating CC node: sends its list of supported codec types and options, listed in order of preference. 

Transit CC nodes: if needed, analyse the received list of options, delete unsupported options from the list and 
forward the list. No modification is done to the preference levels of any of the listed codecs. 

Terminating CC node: analyse the received list of options with their associated priorities and selects the 
supported option with highest indicated priority. 

Figure 5.1/1 illustrates the architecture for Rel-4 for UMTS to UMTS TrFO connection. The transit network may exist 
for calls between PLMNs or between islands of mobile CNs separated by transit networks. This figure is a basic 
illustration, OoBTC shall apply to other access technologies where the OoBTC procedures are supported, i.e. not 
limited to this figure. The negotiation occurs at call set-up phase, and possibly later on in the call due to other changes 
such as handover or relocation. However, as described in the next clause, it shall be possible to modify the selected 
codec at any moment during the active phase of the call. 

Further detail of the Call & Bearer Separation for 3GPP is described in [8]. 
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Control 
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OoB Codec 
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OoB Codec 
Negotiation 




Figure 5.1/1. Basic Architecture for UIUITS to UIUITS TrFO Connection 

The following clauses describe successful call establishment scenarios using the codec negotiation mechanism. 



5.2 Simple call set-up 



The signalling flow for the simple call set-up case is illustrated in figure 5.2/1. Codec negotiation is done prior to the 
establishment of bearer connections, so that appropriate bearer resources are committed to the call. In the proposed 
sequence, the codec negotiation starts with the lAM message containing the list of supported codec types (in this 
example v, w, x, y, z), sent by the Originating MSC (O-MSC). Transit nodes may puncture out (i.e. delete) codec types 
from the list (in this example y). The terminating MSC (T-MSC) selects the codec type (here v) The selected codec is 
conveyed in an APM message, together with the remaining list of alternative, but currently not selected codec types 
(here v, x, z). 
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Figure 5.2/1. Basic Codec Negotiation Sequence 
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The codec list for BICC is specified according to [7], where each 3GPP codec entry is defined according to [5]. 

5.3 Media Gateway Control for Codec Handling 

The general handling of MGW control procedures are detailed in [8]. Specific handling related to the control of the 
speech encoding is detailed in Figure. 5.3/1. The terms context, termination, streams and stream properties are described 
in the ITU-T H.248 "Media Gateway Control Protocol" [13]. 



Stream property: 
Speech codec = codec x 



streams 



Media Gateway 



,\Z 



Stream property: 
Speech codec = codec y 



context 



^>\ 



Termination Tl 



Termination:T2 



<c 



K 



o 



streams 



n 



Figure 5.3/1. MGW control for speech codec 

The handling of transcoding between one codec type (media stream property applied at one termination) and another 
codec type (media stream property at other termination) is a function of the MGW. The media stream property for 
Audio Codec Type is defined in Annex C of the ITU-T MGW control protocol, H.248. 

5.4 UP Framing Protocol Handling for TrFO 
5.4.1 Framing Protocol Initialisation 

For TrFO calls the compressed speech is carried end to end (RNC to RNC or between RNC and other compressed voice 
terminal). In 3GPP Core Networks compressed voice framing protocol shall be specified by the Nb User Plane 
specification. The specification for lu interface is defined in [4], the specification for the Nb interface is defined in [12]. 
The framing protocol for these interfaces is the same, lu framing and is thus described as such, for both the lu interface 
and the Nb interface. For compressed voice only the support mode is used, thus for TrFO the UP Initialisation 
procedure defined for the Nb UP shall be supported by the CN, when a CN MGW is required to establish a connection. 

When negotiating TrFO OoB, a given serving MSC server shall consider the capabilities of the RNCs and MGWs, 
which are candidates to handle the TrFO call and which are controlled by this MSC server via an lu/Mc interface. For 
TrFO, the selected RNC and MGW have to be able to support at least one lu/Nb UP version with TrFO capabilities. 
Each MGW and RNC that supports TrFO shall support lu/Nb UP version 2. If an RNC only supports lu UP version 1 
without TrFO capabilities, the MSC server shall insert a transcoder at the MGW that is connected to this RNC. For a 
TrFO call, each MSC server shall indicate in the "RAB assignment"/" Add request" only UP versions with TrFO 
capabilities. In the inband UP framing protocol version negotiation during framing protocol initialisation, the informed 
RNCs/MGW shall only offer and/or accept UP version listed in the "RAB assignment"/" Add request". 

The lu framing Protocol is established through the CN in a forward direction, independently of the bearer establishment 
direction. The Notify message to indicate bearer establishment shall not be sent until the lu framing has been initialised. 
The continuity message (COT) shall not be sent forward until the Notify message has been received from the MGW and 
also the COT from the previous server has been received. The sequences for mobile originated calls are shown in 
figures 5.4/1 and 5.4/2 for forward bearer and backward bearer establishment, respectively. The parameters in the Add 
Request messages in the Figures are described in further detail in clause 5.4.5. 
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Figure 5.4.1/1: lu Framing Protocol Establishment, Forward Bearer 
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Figure 5.4.1/2: lu Framing Protocol Establishment, backward bearer. 

The transport independent call control procedures in [8] shall support a continuity mechanism, as described above. 

5.4.2 RFCI Storage 

The RNC shall allocate RAB Subflow Combination Indicators to the SDU formats (SDU formats sent to the RNC by 
the MSC in the RAB Assignment). This allocation is then sent in the lu Framing Initialisation PDU by the RNC in the 
User Plane. For farther details see [3] and [4]. 

During the TrFO call establishment each MGW linked into the call shall store the RFCIs received from lu Framing 
PDU Type 14. The first subflow combination in the initialisation frame corresponds to an Initial Rate Control, i.e. 
indicates the highest rate for the first speech mode to be used in the direction of the Initialisation Acknowledgement 
frame. 

After the out of band codec negotiation has been performed, if the originating side is a UTRAN, then on request from 
the MSC for a RAB Assignment, it shall initiate the lu user plane. If the originating side is a network that does not 
support lu Framing then the lu Framing initialisation is initiated by the GMSC, as described in detail in Clause 6.7. An 
Initialisation Protocol Data Unit (PDU) shall be sent to the first MGW in the call connection. Each initialisation leg is 
acknowledged per TrFO Link, i.e. per MGW -MGW interface. The subsequent initialisation is performed using the same 
RFCI set as received from the preceding node, independently of the Stream mode directions (i.e. if the terminations are 
not through connected). 

This is shown figure 5.4.2/1. 

Figure 5.4.2/1: RFCI Storage and subsequent initialisation in MGW 

When the MGW terminations are through-connected and the RFCIs at both terminations are matching, then the MGW 
may revert to transparent mode; the RNCs shall not perform any subsequent lu Framing initialisations without explicit 
request by the serving MSCs. 
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All succeeding MGWs in the path shall behave in a similar way as described above. 

5.4.3 RFCI Value Correction 

At the terminating end of a TrFO connection with lu Framing initialised to the terminating MGW, the originating RFCI 
allocation is stored. The terminating RNC is then requested to perform a RAB Assignment towards the terminating 
MGW. This results in an lu Framing initialisation, where the allocation of the RFCI values is independent from the 
Originating RNC's allocation. These values may then be different to the originating RNC's set. 

The terminating MGW shall acknowledge the lu Framing Initialisation and compare the RFCI values stored from the 
originating side. If the allocated index values do not match, then the MGW shall perform one of the following 
procedures: 

1) initiate an lu Framing Initialisation PDU towards the terminating RNC with the RFCI allocation as defined 
by the preceding node (previously stored in the MGW. This behavior is shown in figure 5.4.3/1 and termed 
'RFCI value correction') As the first Subflow combination received from the terminating RNC corresponds to 
an initial (maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech 
mode back to the preceeding node in the core-network. 

2) map the RFCI indices of the incoming side to the corresponding RFCI indices at the outgoing side for all 
SDUs passed between the lu Framing protocol terminations. As the first Subflow combination in the luUP 
initialisation corresponds to an initial rate control, i.e. indicates maximum rate for the mode to be used (in 
direction of Initialisation acknowledgement frame) it is treated as the initial maximum rate control (see [4]) 
the MGW shall initiate a Rate Control PDU indicating this maximum speech mode toward the terminating 
RNC. Similarly as the first Subflow combination received from the terminating RNC corresponds to an initial 
(maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech mode 
back to the preceding node in the core-network. For further details on the rate control see clause 5.7. 





VIGw Termination 




RFCIs Stored 











MGw 




Figure 5.4.3/1 :RFCI Value Correction 

Further details of the TrFO call establishment are described in clause 6. 

This resolution handling is required also during RNC relocation; further details are described in clause 6. 

5.4.4 TrFO Break 

The event and procedure when a TrFO connection must be interrupted at a certain point in the path, e.g. due to a 
supplementary service invocation or for handover/relocation, is termed "TrFO Break". A TrFO Break may occur at a 
MGW as a consequence of a command directed by the associated Server. During this period the lu User Plane protocol 
is terminated by this MGW, in general at both sides of the MGW. This means that it must respond to new Initialisation 
PDUs and Inband Rate Control PDUs. The MGW inserts a TrFO Break Function, which then makes use of the stored 
RFCI values, in order to perform the required lu Framing protocol functions and interpret the payload. Further call 
scenarios for specific services that incur a TrFO break are described in clause 6.. 



5.4.5 TrFO Break Recovery 



During the TrFO break situation the individual connections are free to change, the RFCIs may have changed and also 
the rate control (maximum rate, current rate). After the service that caused the TrFO break is complete, the MGW shall 
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check if TrFO.can be re-established. If the coding schemes are matching but the RFCI's have changed then RFCI value 
correction can be performed at the RNC side. In order to correct any changes in rate control between two RNCs, the 
MGW shall send a rate control request from each Termination, with the current rate and maximum rate applied at the 
other Termination. This will then result in the Distributed Rate Decision between the two RNCs in the call. 

5.4.6 MGW Control Protocol lu Framing Package properties 

The following is a summary of the lu Framing H.248 requirements; the procedures are described in [12] and are valid 
for lu Framing in Support Mode: 



Additional Package Properties: 

lu Framing Termination Type: Values 

lu Framing Initialisation Procedure: 



lu-RAN (lu Framing Protocol on lu Interface) 

lu-CN (lu Framing Protocol on Nb Interface) 

Values - Incoming (For lu-CN: the lu Framing Protocol initialisation is 
received by the media gateway and used for subsequent initialisation from this 
MGW. For lu-RAN this indicates the originating RNC interface). 

- Outgoing (For lu-CN the lu Framing Protocol is generated by the core 
network MGW, i.e. initialised on the Nb Interface. For the lu-RAN interface 
this specifies the terminating RNC Interface) 



5.5 TrFO/TFO Codec Negotiation Harmonisation 

When OoBTC procedures are initiated to a node where compressed voice cannot be supported (either at the node or to 
the preceding node) then a transcoder is inserted. This can be due to the transport technology (e.g. TDM) or due to the 
access technology (e.g. GSM). The OoBTC procedures can result in the following call scenarios: 
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Figure 5.5/1 : Cascaded TrFO & Transcoding 

In Figure 5.5/ 1 the OoBTC cannot proceed as the call crosses a transit network that does not support compressed voice. 
The same could occur if the transit network did not support out of band codec negotiation (Support in BICC is 
optional). 

In Figure 5.5/2 the OoBTC procedures result in the call terminating to a GSM access. As the GSM radio access 
transcodes to default PCM codec, the OoBTC results in default PCM being the only codec that can be selected. The 
reply is passed back to the originating network, which then inserts a transcoder from default PCM to AMR for the 
UMTS radio access. 
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Figure 5.5/2: UMTS to GSM interworking 

For TFO to establish between the transcoders in the above scenarios, each TRAU must send a codec list inband after the 
call has been established. If a common codec type is available (determined by pre-defined rules, described in TFO 
specification [10]) then the OoBTC procedures need to be informed so that a codec modification can be performed. This 
is shown in Figure 5.5/3. Note - a modification could also be required when a common codec type has been selected but 
the ACS is not common. 
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Figure 5.5/3: TFO support by OoBTC signalling 

In H.248, the vertical MG control protocol, the coding types are specified by Media Stream Property, as defined by 
Annex C of H.248 specification. A specific package is used for TFO. 

The basic requirements are listed below: 

i) Property for Codec List (same format as for [5]) 

ii) Event for common codec determined by TFO protocol 

iii) Event for Far End's Codec List 

iv) Procedures to define TFO 

The TFO package allows the Server to request the MGW to initiate TFO protocol towards a far end transcoder. The 
package includes a property to turn off the TFO (TFO_Active); this may be required prior to TrFO break situations such 
as handover. The control of the level of negotiation is performed by the "Optimisation Mode" parameter in the Codec 
List IE see [5]. This allows a node to indicate if the ACS may be punctured or not and this is mapped to the appropriate 
parameter in the TFO protocol by the MGW. 
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The MGW returns Notification Events for the Far End's Codec List and Common Codec as selected by the Codec 
Selection mechanism in TFO. The Server then compares the "Far End Codec List" with its previously negotiated 
Available Codec List. If the lists are not the same then a Codec List Modification is also performed. 

5.6 CN Node handling of Codec Types & Codec Modes 

The supported codec list received by the MSC in DTAP protocol [2] has no priority, whereas the list sent in the OoBTC 
procedures is sent with a level of preference. 

The default Codec Type for 'R99 UMTS only' terminals is UMTS_AMR, the default Codec Type for all terminals 
supporting GSM and UMTS radio access is UMTS_AMR_2, see [5] for the detailed description. The UMTS_AMR_2 
is a superset of the UMTS_AMR. It behaves as a FR_AMR codec in the UL and as a UMTS_AMR codec in the DL. 
This allows UMTS terminals to operate in TFO with GSM terminals. The UMTS_AMR_2 is fully compatible with 
UMTS_AMR in TFO and TrFO and fully compatible with R99 CN nodes (TC in MGW). 

If the UE supports both Codec Types (UMTS_AMR and UMTS_AMR_2), then the MSC shall indicate only the 
UMTS_AMR_2 in the OoBTC codec negotiation. If no Codec List IE is received and the UE is'UMTS only', then the 
MSC shall assume UMTS_AMR as supported Codec Type. If no Codec List IE is received, but the UE is 'dual system', 
then the MSC shall assume UMTS_AMR_2 as the supported codec type. The MSC shall assume 'dual system' support 
only if the UE indicates at least one GSM speech version in Octet 3a etc. of the Bearer Capability. 

When a codec list contains UMTS_AMR_2 and a node in the network participating in the codec negotiation only 
supports UMTS_AMR then it shall indicate UMTS_AMR back although the codepoints as defined in [5] are different 
and only the UMTS_AMR_2 codepoint is included in the codec list it shall be allowed to signal back the codepoint for 
UMTS_AMR as this is a subset of the UMTS_AMR_2 codec and thus its support is implied. Similarly, if a node 
receives only UMTS_AMR in the codec list but it supports UMTS_AMR_2 it shall reply with the codepoint for 
UMTS_AMR as this is the subset that is compatible. 

In order to support interworking with 2G systems it is recommended that MGWs support 2G EFR codecs (GSM_EFR, 
PDC_EFR, TDMA_EFR). In order to avoid modifications during handover between 2G and 3G systems the MSC 
nodes may give preference to a suitable 2G codec. 

The originating CN node, while performing speech service negotiation with a terminating CN node, shall indicate the 
maximum number of codec modes that shall be selected during speech codec negotiation. This maximum number of 
supported codec modes may depend on optimisation strategies applied by the originating CN node. The recommended 
value is 'four' (see [10]). 

The terminating CN node receiving this information compares the maximum number of codec modes received by the 
originating CN with its own one and shall decide on the minimum of both numbers to be applied as result of the 
negotiation. 

The decision about the actual codec modes to be selected as the Active Codec Set (ACS) shall be left to the terminating 
CN node. In order to provide harmonisation of out of band codec negotiation (TrFO) and inband codec negotiation 
(TFO) very similar codec selection mechanisms as those being defined for TFO shall be applied for TrFO, see [10]. 
These rules shall be taken into account when forwarding a codec list from the originating node to proceeding node, both 
for TrFO and TFO. 

Whenever one or several TrFO links have been already established and initialised, the CN node (e.g. the serving CN in 
case of Call Hold scenarios, the visited CN node in case of Call Forwarding scenarios, etc.) initiating a subsequent 
codec negotiation, shall give the already negotiated codec type, including its ACS, highest preference to reduce the 
possibility of performing bearer re-establishment or UP re-initialisation of the already established and initialised TrFO 
links. 

When the MSC node requests a RAB assignment the Subflow Combinations provided shall either all be initialised by 
the RNC or all rejected with appropriate cause code. 

The MSC shall always assume "Discontinuous Transmission (DTX)" as mandatory and shall define 'SID' SDUs in 
addition to the negotiated speech codec modes. This is because for TrFO the RAB requested by one RNC must match 
that requested by the peer RNC - they are effectively the same RAB. If one MSC requires DTX support then the RAB 
requested by the far end MSC must also support DTX (even if it is not desired by that MSC). As no Out Of Band 
negotiation for DTX is supported nor DTX control to the UE, DTX shall be mandatory for TrFO connections. 
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Once the common ACS has been selected the MSCs shall indicate in the RAB Assignment parameters [3] for the 
Guaranteed Bitrate the lowest speech mode in the ACS (assuming any SID frames are smaller than the SDU for lowest 
speech mode, otherwise the Guaranteed Bitrate shall be set to the largest SID frame). The Maximum bitrate shall 
correspond to the highest mode in the ACS. 

5.7 Inband Rate Control 

Inband rate control shall only allow the RNCs to set the maximum codec mode (maximum bitrate) from the set of codec 
modes that have been negotiated out of band. This procedure is called Maximum Rate Control. The final maximum 
mode selected results from a rate control request from one side and the maximum rate supported at the receiving side; 
the lower rate of these is selected. This is known as Distributed Rate Decision. In TrFO maximum rate control shall be 
supported through the lu Framing protocol and through transit networks supporting compressed voice. The maximum 
rate control procedures are further defined within the lu Framing protocol [4] . 

When the MSC requests for a RAB to be assigned, it shall always define 1 speech mode SDU (lowest rate), and DTX 
SDU as non-rate controllable. Other SDU formats for higher rates shall be defined as rate controllable. The first 
subflow combination in the luUP initialisation shall be treated as an initial maximum rate control. Where a node is in 
TrFO break (e.g. the terminating MGW) this initial maximum rate control received at a given MGW/IuUP termination 
shall be signalled to the other TrFO link using the luUP Rate Control PDU unless the luUP Initialisation frame is to be 
sent on to the next link as in RFCI Value Correction (see clause 5.4.3). 

At SRNS relocation the new RNC shall send a rate control frame at Relocation Detect indicating its current maximum 
rate, it will receive in the acknowledgement the current maximum rate from the far end. This procedure is called 
Immediate Rate Control. Again the distributed rate decision means both RNCs will operate within a common limit. 

5.8 Modification Procedures 

The OoBTC procedures shall support the following modification mechanisms: 

i) Modification of Selected Codec. 

(The codec type of the Selected Codec may be switched to another type within the Available Codec List, and/or 
the Active Codec Set of the Selected Codec may be modified, and/or the Supported Codec Set of the Selected 
Codec may be reduced.) 

ii) Modification of Available Codec List 

(The Available Codec List may be reduced by removing codec types and modes) 

iii) Mid-call Codec Negotiation 

(The Available Codec List is re-negotiated, allowing the addition and removal of codec types and modes 
compared to the previous Available Codec List, and a new Selected Codec is chosen out of the new Available 
Codec List) 

The specific call flows when such procedures may be required are detailed in Clause 6. Further information on the 
Available Codec List and the Selected Codec is provided in Section 5.2. Further information on codec types, codec 
modes, a Supported Codec Set and an Active Codec Set is provided in TS 26.103 [5]. The basic codec negotiation 
principles are defined by the BICC Call Control Procedures (see [6]) but the explicit Mc interface procedures are added. 



5.8.1 IVIodification of Selected Codec 

The codec modification procedures shall support the following changes: 

i) change to currently selected codec type 

ii) reduction of the currently selected codec type"s available codec set (ACS) 

iii) reduction of the currently selected codec type"s supported codec set (SCS) 

iv) reduction of the ACS of any codec in the Supported Codecs List (in addition to any change of the selected 

codec). 
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v) reduction of the SCS of any codec in the Supported Codecs List(in addition to any change of the selected 

codec). 

vi) reduction of the codec types in the Supported Codecs List (in addition to any change of the selected 

codec). 

The procedures described in Q. 1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply. 

In Figure 5.8.1/1 and 5.8.1/2 the basic codec modification procedure is shown. This Figure is an example; the codec 
modification procedure may be initiated by any node within the call. 

Upon Reception of a Modify Codec message (action 5 and 9 in Figure 5.8.1/1), a server node shall check if the Selected 
Codec is altered according to the criteria above. If the Selected Codec is not altered, the procedures in Section 5.8.2 
(Modification of the Available Codec List) apply, otherwise the server node shall send a 'Reserve Characteristics' 
procedure to the attached MGW for the corresponding termination (action 6 and 10 in Figure 5.8.1/1 

To perform a modification of the selected codec at an lu interface, the MSC server shall send a 'Modify Bearer 
Characteristics' procedure to the attached MGW (action 1 and 12 in Figure 5.8.1/1). Upon completion of the 'Modify 
Bearer Characteristics' procedure, the server node shall send a 'RAB Assignment Request' to the radio access network 
(action 2 and 13 in Figure 5.8.1/1). The MSC server shall then wait to receive a corresponding 'RAB Assignment 
Response' message from the radio access network (action 3 and 14 in Figures 5.8.1/2 and 5.8.1/3) before continuing the 
modification procedure. 

An MSC server shall use the 'Reserve Characteristic' procedure for the termination towards the preceeding node (with 
respect to the Modify Codec message) to perform the necessary bearer level modification. The MGW shall respond for 
that termination with the 'Bearer Modified' procedure to indicate that the possible bearer modification to increase 
bandwidth was successful. The MGW shall not wait until the lu UP initialisation is complete before replying with the 
'Bearer Modified' procedure. Each server shall not send forward the modify request to the succeeding node until the 
indication from its MGW that any necessary bearer level modification has been completed (BNC_Modified 
notification). The MSC server shall use the 'Confirm Characteristics' procedure to confirm the modification at that 
termination. 

An MSC server shall use the 'Modify Characteristic' procedure for the termination towards the succeeding node (with 
respect to the Modify Codec message) to confirm the codec modification. 

The specific handling of the lu UP initialisation is described in Section 5.8.4. 

Error Cases are described in Section 5.8.5. 
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Figure 5.8.1/1: Codec Modification Control Procedures 



ETSI 



3GPP TS 23.153 version 4.9.0 Release 4 



21 



ETSI TS 123 153 V4.9.0 (2003-09) 



RAB 

Assignment 
Response 




Successful 

Codec 

Modification 



Successful 

Codec 

Modification 

► 




Terminal/ 
Radio 

Access 



■C 



^ 



MOW A 




Confirm 
Char 



Modify Bearer 
(Conditional if 
bandwidth is decreased) 



Modify Bearer 
(Conditional if 



Modify Bearer 
(Conditional if 



Terminal/ 
Radio 

Access 



bandwidth is decreased) bandwidth is decreased) 



:> 



New Codec 



Figure 5.8.1/2: Codec Modification acknowledgement 

5.8.2 Modification of Available Codec List 

The modification of the Available Codec List shall support the following changes: 

i) reduction of the ACS of any codec in the Supported Codecs List 

ii) reduction of the SCS of any codec in the Supported Codecs List 

iii) reduction of the codec types in the Supported Codecs List 

This shall not include removal of modes from the selected codec, as this would require Selected Codec modification as 
described in 5.8.1. 

The procedures described in Q. 1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply. 

No modification of the user plane and signalling towards the MGWs and radio access network is required. 

In Figure 5.8.2/1 the basic 'modification of available codec list' procedure is shown. This Figure is an example; the 
codec modification procedure may be initiated by any node within the call. 
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Figure 5.8.2/1 : Modification of Available Codec List 



ETSI 



3GPP TS 23.153 version 4.9.0 Release 4 



22 



ETSI TS 123 153 V4.9.0 (2003-09) 



5.8.3 Mid-call Codec negotiation 



The Selected Codec and the Available Codec List can be (re-) negotiated during the call using the 'Mid Call Codec 
Negotiation' mechanism. The Mid-Call Codec Negotiation mechanism results in a new Available Codec List, where 
new codec types or modes not within the previous Available Codec List may be included. The codec negotiation 
procedure is performed as for call set-up. 

The procedures described in Q. 1902.4, clauses 10.4.4 to 10.4.6 [6] shall apply. 

The sequence is shown in Figure 5.8.3/1. Starting with the Modify to Selected Codec message, the remaining sequence 
is the same as for the Codec Modification in Section 5.8.1 except that the message name for the modify request is 
'Modify To Selected Codec' (instead of 'Modify Codec') in order to allow collisions between the two procedures to be 
resolved. Everything stated in Section 5.8.1 shall also aply for the Mid-Call Codec Negotiation procedure. 

The node initiating the 'Mid Call Codec Negotiation' mechanism (MSC Server A in Figure 5.8.3/1) shall select a 
Preferred Codec and a Supported Codecs List, which may contain new codecs and also may not contain codecs from the 
previous Available Codecs List. If the list no longer contains the previous Selected Codec, then a new codec shall be 
selected as Preferred Codec. If the previous Selected Codec exists within the Supported Codecs List, this codec should 
be selected as the Preferred Codec. 

If a server node removes the Preferred Codec, from the Supported Codec List, the node shall select a new Preferred 
Codec. 
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Figure 5.8.3/1 : Mid Call Codec Negotiation 
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5.8.4 Detailed Procedures For lu Framing Protocol & Codec Modification 

The luFP must be initialised sequentially from one end to the other in order to store new RFCIs in each node to allow 
TrFO to resume. The luFP shall be initialised in the backward direction with respect to the Codec Modification/Modify 
To Selected Codec message as shown in Figure 5.8.4/1. 
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Figure 5.8. 4/1 : Successful Codec Modification including luFP 

A MGW receiving a Modify Bearer Characteristics procedure shall be prepared to receive an incoming modify bearer 
procedure, this may be to increase the bandwidth prior to luUP Initialisation or to reduce the bandwidth after the luUP 
Intialisation. The new codec indicated in the Modify Bearer Characteristics procedure shall always result in the MGW 
being prepared to receive an lu UP initialisation for the new codec, even if the SDU format is unchanged. The MSC 
shall send the RAB Parameters IE and NAS Synchronisation Indicator IE to the RNC to indicate that the codec has 
changed and luUP Initialisation shall be generated. 

Each termination receiving a Reserve_Char will initiate bearer level modification to the preceeding node if needed - i.e. 
if the bandwidth needs to be increased to support the new luUP. No luUP initialisation occurs at this point in time. If 
the Codec Modification Request is terminated by a MGW the luUP init through the core-network is triggered by the 
setting of the 3GUP package property 'initialisation direction' to 'OUT' in either the Reserve_Char or the Confirm_Char 
procedure; the MGW shall then start the luUP Initialisation out from that Termination. If the node terminating the 
modification is an RNC then it will generate a new luUP Initialisation toward its access MGW, each Termination shall 
have the initialisation direction set to 'IN'. Each MGW shall in turn acknowledge the luUP Init to the succeeding node 
(with respect to the modification request) and forward the RFCIs in an luUP Initialisation to the preceding MGW (as for 
call set-up). After completing the lu UP initialisation and receiving the'Confirm Characteristics' procedure, the MGW 
may decrease the bandwidth of the corresponding bearer performing the 'Modify Bearer' procedure (if needed) - no 
bearer bandwidth reduction shall be initiated while the UP is still initialised for the old codec. 

An example call sequence is shown in Figures 5.8.4/2 and 5.8.4/3. 
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Figure 5.8.4/2: Mid Call Codec Negotiation Call Sequence. Call Flow Part 1 
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Figure 5.8.4/3: Mid Call Codec Negotiation Call Sequence. Call Flow Part 2 

5.8.5 Unsuccessful Codec Modification 

If the Codec Modification is unsuccessful at a certain node in the connection (due to the MGW rejecting a request to 
reserve the resources or a server rejecting the request to modify the codec) the Confirm_Char message shall be sent to a 
termination that previously performed a successful Reserve_Char Procedure to change the bearer back to its original 
bandwidth (if needed) and free up any reserved resources. However as the luUP has not been modified, the 
Confirm_Char shall not trigger an luFP re-initialisation. The basic sequence is shown in Figure 5.8.5/1 and a detailed 
call flow is described in Figure 5.8.5/2. A server that performed a Modify Bearer Characteristics procedure to a 
termination with the new codec shall perform a subsequent Modify Bearer Characteristics procedure to that termination 
with the old codec in the failure case. As no luFP initialisation occurs in the unsuccessful case the luFP currently 
intialised will then match the old codec restored by the subsequent Modify Bearer Char; the MGW then knows that it 
can return to TrFO. 

The Codec Modification Failure message shall not be returned to a preceding node until notification of the bearer level 
modification (BNC_Modified). 

RAB Assigment Modification Failure 
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If the reason for failed codec modification is due to an unsuccessful RAB Modification Request then the MSC shall 
assume that the old RAB is resumed and thus shall restore the old codec. 
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Figure 5.8.5/1 : Unsuccessful Codec Modification 

luUP Initialisation Unsuccessful 

If the luUP initialisation fails (this must be due to some protocol error or transmission error because the resources have 
already been successfully reserved) then the UP protocol is cleared by the peers (see TS 25.415) and therefore the 
MGW shall notify the Server with a Bearer_Released notification, the call shall be cleared (normal MGW initiated call 
clearing applies - see TS 23.205 clause 7.4 [8]). 
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Figure5.8.5/2: Call Sequence for Unsuccessful Modification. Call Flow Part 1 
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Figure5.8.5/2: Call Sequence for Unsuccessful Modification. Call Flow Part 2 
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5.9 DTMF Handling For TrFO Connections 

DTMF from the UE is sent via DTAP procedures out -band. For a TrFO call the Originating MSC shall use an out-band 
DTMF procedure, all CN nodes shall support this procedure in their call control protocol. The out -band DTMF 
procedure shall also be used when TrFO is not achieved in order that TFO is possible. Insertion of DTMF in the PCM 
payload can result in the break of the TFO connection. 

For terminating calls DTMF may need to be received by the core network (for voice-prompted services, voicemail 
control procedures etc). If the DTMF is received out-band then out-band procedures shall be maintained in core 
network. 

If the DTMF is received for a TrFO call from an external network inband, in 1.366.2 profile or RTP payload type, then 
the gateway MGW which interworks between lu Framing and the external framing protocol shall report the DTMF 
tones via H.248 procedures to its server. The server shall then use out-band procedures to pass the DTMF through the 

CN. See Figure 5.9/1. 

The same shall apply if a DTMF tone is received for a TrFO call from an external network inband in a PCM coded 
stream. The DTMF tone shall be detected by the MGW and reported via H.248 procedures to its server. In order to 
prevent duplication of DTMF tones due to subsequent PCM legs in the call, when encoding to compressed codecs the 
detected tones shall not be allowed to continue in the compressed stream; the DTMF Digits shall be deleted by the 
MGW before entering the speech encoding stage. 

The MGW may also optionally pass DTMF inband where such an option exists for the Nb interface, and is supported by 
the proceeding MGW. 

Transcoding to default PCM to send DTMF tones shall be avoided for TrFO connections. 




Figure 5.9/1 :DTMF received inband from external network 
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Detailed Call Procedures 
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Figure 6.1/1 : Configuration during Call Setup of a Mobile to Mobile Call 

Following network and protocol entities are involved in the scenario, outlined in Figure 6.1/1: 

RNC-T, RNC-O: terminating/originating RNCs. 

MSC Server-T, MSC Server-O: MSC Servers, performing service, i.e. codec negotiation. 

MGW-T, MGW-O: terminating/originating MGWs with the optional capability to insert/remove so called. 

TrFO break equipment: (TBEs), i.e. contexts containing an UTRAN- and a CN side lu Framing termination (Tl - 
T4), inter-working in a distinct manner on control level. [Note: context is meant to be the H.248 specific throughout the 
document]. It is aimed to design protocols for TrFO in a way, that these pieces of HW can be removed after call setup 
phase to allow to revert to "simple" AAL2 switching in case of ATM transport. 

lu FP term.T, lu FP term.o: Terminating- and originating-side TrFO peers (lu Framing terminations in RNCs in Figure 
6.1/1). 

RANAP, TICC:C-plane protocol incarnations, responsible for codec negotiation, controlling the respective interfaces 
(lu, Nc), creating, modifying, removing etc. terminations and contexts. 

The final configuration is (at least logically) an end to end TrFO relation between RNC-T and RNC-O with the option 
to remove the TBEs from the user data path, i.e. to revert to pure AAL2 switching in case of ATM Transport. 
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Figure 6.1/2: Call Setup. Mobile to Mobile Call. Message Flow part 1 
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Figure 6.1/3: Call Setup. Mobile to Mobile Call. Message Flow part 2 
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Figure 6.1/4: Call Setup. Mobile to Mobile Call. Message Flow part 3 

Codec negotiation 

Steps 1. to 6. give the codec negotiation phase. The mobiles inform the network about their capabilities (1. and 4.). 
Afterwards the MSC-Server performs codec negotiation according to clause 5.6. 

Network side bearer establishment 

MSC-T/MSC-O shall request seizure of network side bearer terminations with luFP properties (see steps 5. and 7.). 
Intermediate CN nodes that may perform certain service interactions (e.g. IN nodes) have to seize terminations with 
luFP properties as well. 

RAB Assignment 

RAN side terminations with luFP property have to be seized (9. and 17.) before sending RAB Assignment (steps 10. 
and 18.), that contains RAB parameters according to the selected codec and the negotiated ACS. In addition, the 
respective NAS synchronisation indicator shall be included. 



6.2 SRNS Relocation during TrFO 



In order to maintain TrFO connection in SRNS Relocation, procedures specified in [8] and [11] for "Intra-MSC SRNS 
Relocation" shall be followed. Note that the "Intra-MSC SRNS Relocation" procedure can also be used for relocation 
between RNCs connected to different 3G MS's. 



ETSI 



3GPP TS 23.153 version 4.9.0 Release 4 



34 



ETSI TS 123 153 V4.9.0 (2003-09) 



MSC - Server - A 



RANAP 

(old) 



nterworking 



TICC 



RNC-A 



RANAP 



luUP 
term. A 



RNC-A' 



RANAP 



luUP 
term. A' 




TICC 

partner 

(MSC-S-B) 



TrFO 
> vis-a-vis 
(RNC-B) 



Figure 6.2/1 : Configuration during SRNS Relocation 

Figure 6.1/1 shows the configuration during relocation. After setting up the new lu interface (towards RNC-A') until 
releasing the old one, the original TrFO relation (A<^B) and the target TrFO relation (A'<^B) exist in parallel. Within 
the respective context (TBE) interworking between Tl, T2 and T3 is necessary: 

T3 will perform initialisation towards RNC-A'. 

T2 will hide initialisation performed on 1u,a' from RNC-B. 

If the option to remove the TBE was applied after call setup, the whole context (TBE) needs to be inserted prior to 
performing SRNS Relocation. Initialisation data need to be available within MGW-A. After Relocation, the context 
(TBE) may be removed again, i.e. the MGW-A again acts as a pure AAL2 switch. 
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Figure 6.2/2 :SRNS Relocation and TrFO. Flow chart part 1 
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Figure 6.2/3 SRNS Relocation and TrFO. Flow chart part 2 

RAB Assignment on the new lu leg: 

A RAN side terminations with luFP property (T3) has to be added to the already seized call context (step 2.) before 
sending Relocation Request (4.), that contains all the RAB parameters already applied on the lu leg towards RNC-A. 

UP initialisation 

RNC-A' shall accept the requested set of codec modes and is not allowed to puncture out any negotiated mode. The 
INIT frames shall be according to the RAB parameters received. 

At reception of an INIT frame from the new RNC, the termination at MGW-A shall not perform forwarding of the luFP 
initialisation. The MGW shall check whether the received RFCI allocations match the stored RFCI allocation. If it does 
not match, it may re-initialise the luFP towards RNC-A' at this point in time. 

Removal of TrFO Break Equipment (TBE) 

If the MGW supports the removal of TBEs, it shall insert the TBE before seizing the additional termination. It may 
again remove the TBE after performing RFCI matching and through-connection of the new termination and the 
termination to the far end party. 



6.3 



IN and Call Forward SS 



In some cases, IN services (e.g. voice prompting) are triggered at CC-IN nodes that require the establishment of an UP 
bearer for tones or announcements to be sent to the calling party. In order to establish this bearer, it is necessary that the 
CC-IN node temporarily selects one codec from the codec list sent from the initiating node, and informs the initiating 
node about the selected codec. Afterwards, the call may continue its establishment to the another node, which may not 
support the selected codec but requests that another one in the list be selected instead. 
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A similar situation arises with the CFNRy supplementary service. A UP connection needs to be established between the 
originating and "provisional" terminating CC nodes to enable ringing tones to be sent to the calling party. The type of 
codec must be agreed prior to the establishment of the bearer connection. Afterwards, the call is redirected to another 
node that may not support the selected code but requests the selection of another one. 

6.3.1 TrFO interworking with SS (VMSC = service interworking node) 



1" TrFO relation (RNC-0 ^ RNC-T) 



(or RNC-0 <^ MGW-T in case MGW-T applies a tone/announcment) 




2"" (re-negotiated) TrFO relation (RNC-0 « RNC-T') 



Figure 6.3.1/1. Codec Modification in case of SS interworl<ing 

In case of supplementary service interworking, it may become necessary to apply codec modification out of band. 
Figure 6.3.1/1 shows the network model, that may apply for a certain set of SS's (call deflection (CD), call forwarding 
on no reply (CFNRy), CF on user determined busy (CFUB), etc.). Common to these scenarios is: 

the service interworking is controlled by the VMSC (this is common to all SSs). 

MSC-T extends the call towards MSC-T' according to the forwarded-/deflected-to-number. 

An intermediate TrFO relation will in general already exist between two RNC's (RNC-O and RNC-T in figure 6.3.1/1) 
before the call is diverted to another node, as the ringing tone was applied in backward direction. 

In order to perform codec negotiation with the third node (MSC-T') as well it is necessary to forward the supported 
codec list from MSC-O. MSC-T' signals back the codec it selected and the available codec list. If the codec negotiation 
result is different from the previously performed codec negotiation between MSC-O and MSC-T, MSC-O shall be 
informed. MSC-O shall be able to decide based on the received modified codec type whether lu Framing re- 
initialisation and bearer modification is required. This scenario is depicted in Figure 6.3.1/2 below. If no codec 
modification has to be appHed, MSC-T(B) shall extend the UP initiahsation towards MSC-T'(C), i.e. MSC-T(B) shall 
initialise a termination (TC) with the property Initialisation Procedure = incoming. MSC-T' (C) shall also initialise a 
termination TC with the property Initialisation Procedure = incoming. Further call handling follows the mobile to 
mobile call estabhshment (see clause 6.1). 
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Figure 6.3.1/2: Codec Modification for SS-interworiting & UP re-initialisation 
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6.3.2 IN interworking (VMSC ^ service interworking node) 
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Figure 6.3.2/1. Codec Modification in case of IN interworking 

Common to IN interworking scenarios is that service interworking is controlled by an IN service node that is generally 
not the VMSC. 

IN interworking (i.e. in case of a separate IN service node, this is often a Gateway-MSC) may interrupt call 
establishment and apply an intermediate announcement back to the originating side. This means, that codec negotiation 
was in fact performed between the IN service node and the MSC-O. 

When performing further call establishment, it is necessary to proceed with codec negotiation towards MSC-T. The 
codec negotiation process shall consider the capabilities of MGW-IN. 

IN services, similar to call forwarding SS, are possible. The fact that this service interworking is controlled by an IN 
service node, may cause, that the leg towards MSC-T has to be released and a new leg towards MSC-T' will be 
established. Codec negotiation is again necessary from MSC-IN on. 

The sequence chart given in figure 6.3. 1/2 applies in principle for the T' and the 2° negotiation scenarios with 
following modifications: 

as MSC-IN may be involved in subsequent service interworking again, the capabilities of MGW-IN shall be 
taken into account during codec negotiation with MSC-T or MSC-T'. This means, that the codec list forwarded 
to the succeeding nodes is in fact the available codec list of the T' negotiation. 

For the 3"* negotiation scenario, the leg between MSCin(B) and MSC-T (C) has to be released and a new leg 
toward MSC-T'(D) has to be setup. 
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6.4 Information flow for interaction with Multiparty SS 
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Figure 6.4/1 : Multi-party Call 

The operation of the MGW for conference calls is implementation dependent. The sequence in Figure 6.4/1 shows three 
connections to the MGW, where two were configured TrFO and have matching codecs but the third connection could 
not be made with the same codec type. 

The lu Framing connections for each multi-party call leg shall be terminated in the MGW where the multi-party call is 
controlled. The MGW shall control each connection independently during the multi-party call. 

When the multi-party call is released, if two parties remain in the connection it shall be possible to either revert directly 
to a TrFO connection if both codecs match or OoBTC procedures could be performed to modify one or both of the 
codec types to achieve a TrFO connection. However, if the Server does not perform this then the MGW shall continue 
to resolve the difference in codecs by internal transcoding procedures. 

Codec modification procedures may be employed (see clause 5.8.1) if a common codec exists, this is shown in Figure 
6.4/2, where codec v is common to all parties. 



£75/ 



3GPP TS 23.153 version 4.9.0 Release 4 



41 



ETSI TS 123 153 V4.9.0 (2003-09) 



Server A 



Server B 



MGW-A 



Modify C odec (v) 



Modify Clic r Codec (v) 

► 

Successful (^odec Mod 



Reserve Char ( lodec (v) 



Server C 



MGWB 



MGWC 



Confirm Char (^odec (v) 
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Figure 6.4/2: Multi-party Call, with codec modification 

Information flow for handover from UMTS to GSM after 
TrFO establishment 



Inter-system handover procedures are described at call control level in [11] and details for bearer independent 
architecture is described in [8]. For TrFO connected UMTS call, when a handover occurs to GSM radio access, by 
definition the A-interface to the BSC shall be default PCM. Prior to receipt of Handover Detect the Anchor MGW has 
one leg (A-interface) stream mode as default PCM and two terminations with compressed voice codec properties. It is 
recommended that after the Handover Complete procedure, the network property is maintained as compressed. Thus the 
Anchor MGW inserts a "TFO Partner" transcoder. Thus no modification to the compressed bearer to 64k PCM is 
required. TFO procedures may then ensure that speech quality is maintained by avoiding transcoding. 

In the Intra-MSC case shown in Figure 6.5/1 the MSC controlling the handover has both codec lists for each radio 
access. The codec negotiation for the UMTS call was performed end to end with UMTS list. If this negotiation resulted 
in a codec being selected that is also included in the GSM list then at handover the MSC shall indicate this codec as the 
current speech version to the BSC and TFO can be achieved. If the selected codec is not supported for the GSM radio 
access but the GSM list contains a codec that is also in the Available Codecs list then the MSC has the option to 
perform codec modification to ensure TFO can be achieved. The MSC may also perform codec list modification by 
sending forward the GSM list to update nodes in the network of the change to the Available Codecs List. 
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Figure 6.5/1 : UMTS to GSM Inter-System Handover 
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If the Inter-system handover is an inter-MSC handover then the Anchor MSC sends the current speech version and the 
supported speech versions in the Prepare Handover Request message to the MSC-B. If the current speech version 
(codec selected for UMTS call) is not included in the GSM list then the MSC-A shall indicate a preferred codec in the 
current speech version parameter. The speech version for the GSM access that is finally selected by the MSC-B's BSS, 
is returned to MSC-A in the Prepare Handover Response message. The MSC-A can then decide if codec modification 
or codec re-negotiation shall be performed as described for the intra-MSC case. The MSC-B shall always assume 
default PCM across the E-interface, as there is no possibility to perform codec negotiation prior to performing the 
handover. The connections are shown in Figure 6.5/2. 
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Figure 6.5/2: Inter-MSC, UMTS to GSM handover 



6.6 



Call Hold/Call Wait 




Figure 6.6/1 : Configuration during Call Hold/Call Wait scenario 

This scenario assumes subscriber C (served by RNC-O") calls subscriber B (served by RNC-T), currently in 
communication with subscriber A. Subscriber C receives a tone/announcement, applied by terminating side. Then 
subscriber B puts subscriber A on Hold and A receives an announcement (applied again by terminating side.) 

MGW-O has to establish an originating side call context (T4, T5), MGW-T the respective terminating one (T3 only, Tl 
from subscriber will be moved to it during the scenario), the B party context has to be inserted into path again (if TBE 
was removed). 
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Figure 6.6/2: Call Hold/Call Wait and TrFO. Message flow part 1 
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Figure 6.6/3: Call Hold/Call Wait and TrFO. Message flow part 2 
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Figure 6.6/4: Call Hold/Call Wait and TrFO. Message flow part 3 
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Figure 6.6/5: Call Hold/Call Wait and TrFO. Message flow part 4 
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6.7 



External Network to Mobile TrFO Call Establishment 
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Figure 6.7/1. Configuration during Call Setup of a External Network to lUlobile Call 

The description of Figure 6.1/1 (Configiiration during Call Setup of a Mobile to Mobile Call) within clause 6.1 applies 
for the network and protocol entities involved in the External Network to Mobile Call scenario with following 
modifications: 

No RNC-O is present - a party served by an external network originates the call instead. 

The originating CN nodes are Gateway nodes (Gateway MSC Server/Gateway MGW). 

The Gateway MGW call context is no TrFO break equipment in general, i.e. Tl in general do not support the luFP 
framing protocol. Appropriate interworking (in some cases transcoding) has to be performed between Tl and T2. 

Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply in principle as 
well with appropriate modifications outlined below; 

Codec negotiation 

Step 1. Until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: 

There is no originating UE involved in this negotiation phase 

If the preceding node of the Gateway MSC-Server doesn't support OoBTC procedures for compressed voice types, the 
Gateway MSC-Server shall initiate OoBTC procedures in order to enable transcoders placement at the edge gateway 
node. 

The edge gateway node shall always send the complete list of the codec types and modes it supports for this type of call 
setup. 

UP initialisation 

The main difference compared to the Mobile to Mobile call setup is, that the CN side termination of the Gateway MGW 
(T2 in figure 6.7/1) shall start the initialisation of the luFP according to the result of the codec negotiation. The forward 
initialisation principle shall be followed in any setup scenario. 



ETSI 



3GPP TS 23.153 version 4.9.0 Release 4 



48 



ETSI TS 123 153 V4.9.0 (2003-09) 



6.8 



Mobile to External Network TrFO Call Establishment 
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Figure 6.8/1. Configuration during Call Setup of a Mobile to External Network Call 

The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 applies 
for the network and protocol entities involved in the External Network to Mobile Call scenario with following 
modifications: 

No RNC-T is present - a party served by an external network is the terminating side of the call instead. 

The terminating side CN nodes are Gateway nodes (Gateway MSC Server/Gateway MGW). 

The Gateway MGW call context is no TrFO break equipment in general, i.e. T4 in general do not support the luFP 
framing protocol. Appropriate interworking (in some cases transcoding) has to be performed between T3 and T4. 

Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply in principle as 
well with appropriate modifications outlined below; 

Codec negotiation 

Step 1. Until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: 

There is no terminating UE involved in this negotiation phase. 

If the succeeding node of the Gateway MSC-Server doesn"t support OoBTC procedures for compressed voice types, the 
Gateway MSC-Server terminates the OoBTC procedures in order to enable transcoders placement at the edge gateway 
node. 

The edge gateway node shall accept the codec MSC-0 prefers and shall not puncture out any codec mode. 



7 Interactions with supplementary services 

7.1 Call Deflection service (GSM 23.072) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is 
applied. 
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7.2 Line identification services (GSIVI 23.081 ) 

7.2.1 Calling Line Identification Presentation (CLIP) 

No impact. 

7.2.2 Calling Line Identification Restriction (CLIR) 

No impact. 

7.2.3 Connected Line Identification Presentation (COLP) 

No impact. 

7.2.4 Connected Line Identification Restriction (COLR) 

No impact. 

7.3 Call forwarding services (GSM 23.082) 

7.3.1 Call Forwarding Unconditional (CPU) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is 
applied. 

7.3.2 Call Forwarding on mobile subscriber Busy (CFB) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is 
applied. 

7.3.3 Call Forwarding on No Reply (CFNRy) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clauses 6.3 
is applied. 

7.3.4 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clauses 6.3 
is applied. 

7.4 Call wait (GSIVI 23.083) 

In order to apply the notice tone to the interjected party, the speech insertion procedure described in clause 6.4 is 
applied. 

7.5 Call hold (GSM 23.083) 

In order to apply the notice tone to the held party, the speech insertion procedure described in clause 6.4 is applied. 

7.6 Multiparty (GSM 23.084) 

In order to mix calls, the speech insertion procedure described in clause 6.4 is applied. 
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7.7 Closed user group (GSM 23.085) 

No impact. 

7.8 Advice of charge (GSM 23.086) 

No impact. 

7.9 User-to-user signalling (GSM 23.087) 

No impact. 

7.10 Call barring (GSM 23.088) 

7.1 0.1 Barring of outgoing calls 

No impact. 

7.10.2 Barring of incoming calls 

No impact. 

7.1 1 Explicit Call Transfer (GSM 23.091 ) 

In case that a call A-B is transferred to C by B (A-C as result), A-B may use codec x, A-C may use codec y, the 
procedure described in clause 6.3 is applied. 

7.12 Completion of Calls to Busy Subscriber (3G TS 23.093) 

Within CCBS there exists an option for CCBS calls where a bearer can be established before setup in the 
state "CC-establishment confirmed". If the selected codec after setup is different to the one which was used to establish 
the bearer, RAB assignment (modify) may be required when RAB parameters are different. 

8 Charging 

The selected codec shall be included in all the call data records of the call legs involved in out-band codec negotiation 
belonging to a particular subscriber. 
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Annex A (informative): 
Codec Re-negotiation 



A node may perform a procedure (e.g. handover) that results in a completely new list from that which was originally 
negotiated. Assuming that the current Selected Codec is still common (no Selected Codec Modification or re- 
negotiation) then the node shall send a Re-negotiation Request with the new Supported Codec List. The Supported 
codec list may then be punctured by nodes in the network in the same was as for the basic Codec Negotiation procedure 
and a new Available Codecs List returned. 

If a node performs a procedure (e.g. handover) that results in both a completely new list and also the need for a new 
codec then Codec Re-negotiation may be performed with a request for a new codec selection. The procedure is then the 
same as for an initial codec negotiation. 
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